Enumerates every ContentNode type brit introduces to the Elohim
Protocol vocabulary, with pillar couplings (lamad / shefa / qahal),
relationships, signals, and the feature-module boundary that keeps
brit-epr usable as a generic trailer engine.

Exploration only — no code yet. Subsequent tasks consume this doc
to revise the Phase 0+1 implementation plan and scaffold the
brit-epr crate.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Elohim Protocol manifest for brit as an LLM-first development tool
that stays backward-compatible with stock git hosting. Enumerates:

  - brit-epr engine vs. elohim-protocol app schema feature boundary
  - LLM-first CLI command surface (git-analogous verbs)
  - Skill + template artifacts for trivial LLM-driven committing
  - ContentNode type catalog (Repo/Commit/Tree/Blob/Branch/Tag/
    Ref/Fork/DoorwayRegistration/PerBranchReadme + extension slots)
  - Commit trailer specification (canonical summary, hybrid (c))
  - Linked-node resolution protocol via doorway bridge
  - Backward compatibility with GitHub/GitLab/Codeberg/sourcehut
  - Protocol signals brit emits
  - Doorway registration format
  - Cross-references to the p2p-native build system roadmap

Exploration only — no code. Next task consumes this doc to revise
the Phase 0+1 implementation plan and scaffold the brit-epr crate
behind the elohim-protocol cargo feature.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…(closed vocabulary)

Two §14.1 open questions resolved after human review:

  §14.1 GitoxideLabs#3 — Steward key recovery is NOT a brit-schema concern. It
  lives in the Elohim Protocol social recovery substrate: the steward's
  key material is stored as sharded blobs EPR-addressed to family,
  friends, and institutions, and recovery reconstitutes N-of-M shards
  from that social graph. Solo repos are not a special case — every
  repo has a social recovery graph underneath because the protocol
  substrate guarantees one. §10 updated to reflect this; co-steward
  quorum rotation remains valid as a layered safety mechanism, not a
  replacement.

  §14.1 GitoxideLabs#6 — Pillar vocabulary is CLOSED within the elohim-protocol
  app schema. The extensibility axis is the feature-module boundary
  itself: different apps (carbon-accounting, music-composition, etc.)
  supply their own EPR manifests through their own app schemas plugged
  into the same brit-epr engine. Per-repo commit-template.yaml carries
  DEFAULTS and HINTS, not enum extensions. §6.5 example block relabeled
  from "enum extras" to "defaults and hints".

§14.1 GitoxideLabs#4 (brit merge async default) remains open and is being
pressure-tested against distributed stewardship + collective consent
in a separate critique pass.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Pressure-tests the §14.1 GitoxideLabs#4 lean (async-by-default with --wait
escape hatch) against 7 distributed-stewardship and collective-
consent scenarios. Affirms / modifies / replaces the design based
on findings. Identifies where the current §3.9 merge flow, §9
signals, and §14.1 GitoxideLabs#12 protection rules DSL need adjustment to
support consent that is distributed in time and space.

Findings only — no schema edits applied yet; those are listed as
concrete proposals for a subsequent edit pass.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…ync-default resolved

Applies the concrete schema changes proposed by the 2026-04-11 merge
consent critique pass and adds the parent-EPR governance framing from
human review.

Changes:

  §3.1 — brit merge command row rewritten to reference §5.13 proposal
         lifecycle, JSON stdout contract, --wait as polling-cap,
         --withdraw flag, explicit "brit does not own governance" note.

  §3.1 — brit attest row reframed as unified attestation + consent
         surface; --proposal <id> --consent and --as-delegate-of for
         delegated consent.

  §5.12 — MergeConsentContentNode marked superseded by §5.13.

  §5.13 NEW — MergeProposalContentNode promoted from reserved slot to
         fully specified type. Content-addressed immutable core,
         mutable state signal-driven. State machine open →
         partially-satisfied → consented | rejected | expired |
         withdrawn. Required/optional fields. Critical framing: brit
         owns the proposal type; the parent EPR owns governance.
         Adapter at the doorway projects between brit and the parent
         EPR's governance engine. Same model as GitHub branch
         protection — brit enforces policies configured by the parent
         EPR, doesn't invent governance.

  §5.14 — existing "Cross-cutting: what's deliberately not a new type"
         renumbered to make room for §5.13.

  §9.1 — signal catalog: brit.merge.proposed payload rewritten to
         carry proposal_cid + frozen requirements. Four new signals:
         brit.merge.tally.progress, brit.merge.requirement.satisfied,
         brit.merge.expired, brit.merge.withdrawn. brit.merge.consented
         payload extended with consenting_kind and consenting_agents.

  §14.1 GitoxideLabs#4 — RESOLVED. Async-by-default with §5.13 lifecycle. Parent-
         EPR framing: brit reads protectionRules pointing at a
         qahal_node in the parent EPR's governance context; brit
         freezes the resolved requirements into the proposal; the
         parent EPR's governance engine runs the tally. Phase 1 scope
         explicitly EXCLUDES merge consent — trailer foundation only.

  §14.1 GitoxideLabs#12 — entanglement with §14.1 GitoxideLabs#4 noted. Protection rules DSL
         and merge consent co-resolve in a single Phase 2 design pass.

Critic findings at docs/schemas/reviews/2026-04-11-merge-consent-critique.md.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…overnance

The earlier schema invented branch-level "protection rules" as a
brit-specific governance concept. Human review pointed out that
every ContentNode in the protocol already has reach (qahal visibility
coupling), so every brit branch already HAS a reach — we just hadn't
named it as the central primitive. Naming it changes the shape of
the whole merge + governance story.

Changes:

  Reach enum vendored from Elohim Protocol:
    schemas/elohim-protocol/v1/enums/reach.schema.json
      ["private", "self", "intimate", "trusted", "familiar",
       "community", "public", "commons"]
    All DNA-notarized, enforced by doorway, consumed by brit at
    build time (standalone — no path dep on elohim monorepo).

  §5.5 BranchContentNode
    - Reach added as a REQUIRED field, drawn from the vendored
      protocol enum. Reach is per-ref (the branch has the reach;
      commits inherit the reach of the ref that reaches them).
    - protectionRules → extraProtectionRules (optional extras
      LAYERED ON TOP of reach-change rules, not a replacement).
    - New "Branch lifecycle through reach" section showing how
      a feature branch climbs self → trusted → community → public.
    - "Exploratory peer model" paragraph: a branch at reach=self
      is an LLM agent's experiment; nothing propagates. Trust
      elevation is first witness act.

  §5.13 MergeProposalContentNode
    - Retitled: "also known as a reach-elevation proposal".
    - sourceReach and targetReach added as required fields.
    - reachElevation derived boolean; false cases take fast paths.
    - requirementsFrozen now says: "derived from the protocol's
      reach-change governance rules for the sourceReach → targetReach
      transition, plus extras".
    - Framing text explicit: brit is NOT inventing merge governance;
      it's using the same reach-change machinery that governs every
      other reach elevation in the protocol. A commit becoming
      visible to the network is no different from any other piece
      of content becoming visible to the network: the reach gate
      applies.

  §9.1 signal catalog
    - brit.branch.created payload includes reach.
    - brit.branch.reach.elevated NEW — gossipped when a branch's
      reach climbs (self → trusted, trusted → community, etc.).
    - brit.branch.reach.reduced NEW — quarantine / withdrawal.
    - brit.branch.protection.changed renamed to
      brit.branch.extra-protection.changed to reflect that reach
      changes have their own signals.

  §14.1 GitoxideLabs#12 RESOLVED (mostly dissolved)
    - The "force-push policy DSL" open question largely disappears
      into the reach reframe. Reach is the central governance
      gate on branches; reach-change consent rules already exist
      in the protocol. extraProtectionRules is a small residual
      for additive constraints (e.g., "public branch ALSO
      requires security-audit attestation").
    - The entanglement with §14.1 GitoxideLabs#4 is reduced: MergeProposal's
      requirementsFrozen = (reach-change rules at target reach)
      + (extras from extraProtectionRules). Both from the
      substrate, not a brit-specific language.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Rewrites the Phase 0+1 implementation plan to reflect the schema work:

  - Engine vs. app-schema boundary established from Task 0. The
    brit-epr crate ships with an unconditional `engine` module
    (AppSchema trait, TrailerSet, trailer block parser, errors) and
    a #[cfg(feature = "elohim-protocol")] `elohim` module with the
    concrete ElohimProtocolSchema implementation.

  - Phase 1 scope tightened: commit trailer parsing + structural
    validation + brit-verify CLI. Explicit exclusions:
      * MergeProposalContentNode + async merge consent (Phase 2+)
      * Reach awareness on branches (Phase 2+)
      * ContentNode adapter (Phase 2+)
      * CID parsing / resolution — raw strings only (Phase 2+)
      * Signal emission (Phase 2+)
      * libp2p transport (Phase 3+)
      * Full brit-cli subcommand surface (Phase 3+)

  - Tasks restructured around the engine/elohim split:
      Task 0  Scaffold crate with feature-module layout
      Task 1  Engine — AppSchema trait, TrailerSet, errors
      Task 2  Engine — parse_trailer_block via gix-object (TDD)
      Task 3  Elohim — PillarTrailers, TrailerKey, schema impl
      Task 4  Elohim — parse_pillar_trailers (TDD, 3 fixtures)
      Task 5  Elohim — validate_pillar_trailers (TDD, 4 cases)
      Task 6  brit-verify CLI (end-to-end smoke test)
      Task 7  Submodule pointer bump in parent monorepo

  - References schema doc as source of truth for types. When plan
    and schema disagree, schema wins and the plan gets a follow-up.

  - --no-default-features build check in Task 5 Step 5.5 proves
    the engine compiles without the elohim module — the boundary
    check that keeps brit legible as a standalone gitoxide fork.

Supersedes 42e04b0's initial draft. 1479 lines, 7 tasks, ~40
bite-sized steps.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Establishes the engine-vs-app-schema boundary from day 0. The engine
module is unconditional; the elohim module is gated behind the
elohim-protocol cargo feature (default on). Subsequent tasks land the
trait, types, parser, and validator.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Engine layer is now independently compilable with --no-default-features.
Proves the engine/app-schema boundary holds from day 0: the engine
knows nothing about Lamad/Shefa/Qahal specifically.

trailer_block.rs is a stub that Task 2 replaces with the real
gix-object-backed implementation.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Wraps gix_object::commit::message::BodyRef::trailers() into a
schema-agnostic TrailerSet. Engine-level tests prove extraction
works for happy path (4 trailers in canonical order) and no-trailers
case.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

ElohimProtocolSchema implements AppSchema with closed vocabulary
(Lamad/Shefa/Qahal summary keys + their -Node CID counterparts).
Phase 1 stores raw CID strings without parsing — CID resolution
arrives in Phase 2.

parse.rs and validate.rs are stubs that Tasks 4 and 5 replace with
the real implementations.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Projects engine's schema-agnostic TrailerSet into the typed
PillarTrailers view. Permissive: unknown trailers skipped, malformed
node refs stored as raw strings. Three fixtures cover happy path,
partial declaration, and malformed node-ref.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

validate_pillar_trailers enforces all three pillar summary trailers
are present and non-empty. Errors in canonical order Lamad → Shefa
→ Qahal. No CID resolution, no graph traversal — those are Phase 2.

Closes out brit-epr crate for Phase 1: 9 tests passing (engine 2,
elohim parse 3, elohim validate 4), engine compiles cleanly with
--no-default-features.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Opens a repo, resolves a rev, parses pillar trailers via brit-epr,
runs structural validation, exits 0/1/2/3. No clap, no tracing —
smallest possible end-to-end proof that the engine + elohim schema
work against real git objects.

Smoke-tested end-to-end during implementation:
  - valid commit with all three pillars → exit 0, pillars printed
  - upstream gitoxide commit → exit 1, missing pillar reported

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Replaces gitoxide's stock README with the brit vision document.
Covers:

  - Why: siloed economic/informational/social power and how coupling
    the three pillars (lamad/shefa/qahal) at the protocol level
    addresses it

  - Four concrete unlocks:
    1. Built-in contributor payment (shefa flows with the commit)
    2. Provenance-aware code (choose who stewards the code you depend
       on — Amazon vs Coop AWS example)
    3. Deployment-aware code (EPR links that resolve per branch/env)
    4. Fully distributed landing via IPFS/IPLD — but unlike other
       crypto/P2P projects, landing in a network designed to scale
       wisdom and care, not speculation

  - How: commit trailers (backward-compat RFC-822), doorway bridge
    (web2 ↔ protocol), engine/app-schema split (pluggable by design)

  - Status, quick start, relationship to gitoxide, further reading

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…ward roadmap

Brings brit's documentation to the same level as rakia:
- Design spec (docs/specs/2026-04-12-brit-design.md): formal spec
  capturing schema manifest decisions, acceptance criteria, design
  decisions, open questions
- Composition model (docs/composition.md): how brit composes with
  rakia, protocol schemas, rust-ipfs, storage/steward infrastructure
- Phase 2-6 summaries (docs/plans/phases/): each phase documented
  with vision, prerequisites, sprint sketch, risks, and what it
  unlocks for rakia and the protocol
- Roadmap reframed by protocol capability (docs/plans/README.md):
  phases decomposed by what the protocol gains, not what crate
  gets written. Parallel evolution table with rakia.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Recovered Phase 2a design doc (build attestation primitives) placed in
docs/plans/phases/. Implementation plan at docs/plans/. Added .worktrees/
to .gitignore for future worktree isolation.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Introduces the ContentNode trait for CID-addressed serialization and
LocalObjectStore for filesystem-backed content-addressed object storage
under .git/brit/objects/.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Adds AgentKey for load-or-generate keypair management (32-byte seed
files) and a standalone verify_signature function for hex-encoded
ed25519 signatures, wiring the signing module into the engine's public
API.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Adds BuildAttestationContentNode, DeployAttestationContentNode, and
ValidationAttestationContentNode under the elohim::attestation module,
each implementing ContentNode with camelCase serde and 5 roundtrip tests.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Introduces BritRefManager with read/write/list operations for build,
deploy, validate, and reach ref families under refs/notes/brit/. Uses
git notes for per-commit build refs and blob refs for standalone deploy
and validation refs. Path segments are percent-encoded to sanitize
step names containing colons and at-signs.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Adds ReachLevel enum (Unknown < Built < Deployed < Verified) and
compute_reach() function that derives reach from the presence of build,
deploy, and validation attestations deterministically.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

… refs

Implements the `brit-build-ref` binary (Task 7, Phase 2a) with clap 4 derive API.
Supports put/get/list for build (per-commit notes), deploy, and validate refs, plus
reach compute/get. All commands auto-load/generate an ed25519 agent key, sign
attestation payloads, and store nodes in the local object store.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Re-export attestation types at crate root behind elohim-protocol
feature flag. Engine-only build verified: --no-default-features
still compiles.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Mark Phases 0 and 1 as complete. Add Phase 2a (build attestation
primitives) to the roadmap table with link to implementation plan.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Replace redundant closure with method reference in list_refs_under.
Allow too_many_arguments on build put function (CLI arg passthrough).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

- canonical_json now recursively sorts JSON object keys via BTreeMap,
  making CID computation truly order-independent across implementations
- list_refs_under decodes percent-encoded segments so callers see
  original step/check names (fixes reach compute with colon steps)
- Agent key file written with 0600 permissions on unix (private key
  must not be world-readable on shared CI)
- Object store uses atomic write (temp + rename) to prevent partial
  files on crash
- Replaced unwrap() on stdin pipe with proper error propagation

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

… (--check/--update/--candidate)

…ore staging dirs

…terministic SHAs

…ne/fetch/push tests)

…ith stable-SHA allowlist)

…s + optional normalization)

…g + library facade

…ncovered + percent)

…command captures)

…+ discovery + format + diff

Replaces scaffold main.rs with full runner: discovers subcommands via
recursive --help, invokes cli-journey tests into staging, formats the
markdown test page, and dispatches on check/update/candidate mode.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…l 8 subcommands with staging dump

Adds rakia.sh shell smoke (--help + no-arg exit-2), sources it from journey.sh,
and adds cli-journey/tests/rakia.rs with one test per leaf subcommand. Each test
dumps normalized output to BRIT_TEST_PAGE_STAGING/rust/rakia/<path>.txt using
the hierarchical staging_dump_path helper so the runner reconstructs full paths
(e.g. graph/discover.txt, baseline/read.txt). All 8 tests pass; 8 staging files
produced in correct directory hierarchy.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…staging dump

brit-verify is a single-purpose binary (no clap, no subcommands). Three
tests cover: no-args usage error (exit 2), missing trailers (exit 1), and
valid trailers round-trip (exit 0). Adds commit_file_with_message to TestRepo
to support commits with custom messages (e.g., pillar trailers). Staging
artifact lands at rust/brit-verify.txt showing the validated passing output.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

… all leaf subcommands

11 leaf subcommands covered (build/deploy/validate: put+get+list; reach: compute+get).
Each leaf has a Rust test that invokes against a temp repo and dumps captured output to
BRIT_TEST_PAGE_STAGING/rust/brit-build-ref/<group>/<leaf>.txt.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…og, status, diff, branch, commit, clone, fetch, push, tag, blame, cat)

16 tests cover all 11 daily-driver slots. brit push is not yet
implemented in gitoxide — documented as a gap with a placeholder
staging dump. diff expands to two leaves (tree, file); commit
expands to two leaves (describe, verify); branch and tag each have
list; clone and fetch exercise MockRemote with file:// transport.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Available for per-binary journey shells (rakia.sh, brit-verify.sh,
brit-build-ref.sh) to feed shell-side captures into the cli-test-page
runner's staging directory. No-op when BRIT_TEST_PAGE_STAGING is unset
so journey.sh stays standalone-safe.

Not yet wired into the existing shell tests because Task 17's recast
moved the rich CLI coverage into Rust integration tests (where the
structured-output binaries can be asserted on properly). The helper
exists for future shell-only test scenarios where Rust tests are
inappropriate (e.g., terminal-attached interactive subcommands).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…oughput; commit initial baseline

Normalizer now redacts:
  - HH:MM:SS clock times → <CLOCK> (gitoxide progress lines)
  - X.XXs durations → <DUR>
  - throughput rates (objects/s, MB/s, etc.) → <RATE>

These are pervasive in gitoxide's progress output and were causing
non-determinism between consecutive test runs.

Initial baseline.md committed:
  - brit:           12/70 covered (17%) — daily-driver subset
  - rakia:          8/8 covered (100%)
  - brit-verify:    1 binary, single capture
  - brit-build-ref: 11/11 covered (100%)
  - Total:          31 / 89 across the 4 binaries

Coverage gap on brit (58 uncovered subcommands listed in baseline.md)
becomes the carry-over for follow-up sprints to chip away at as we
dogfood. Each subcommand can be added in ~10 lines (TestRepo + invocation
+ staging dump).

Known remaining non-determinism: brit cat output varies (5 lines
of diff between consecutive runs). Probable root cause: brit cat on a
commit SHA sometimes resolves to commit text, sometimes to underlying
blob. Captured as carry-over.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Sprint: 2026-04-19 brit CLI test page.

  - cli-journey crate: TestRepo + MockRemote + Normalizer + BritInvocation
    helpers (15 self-tests) + per-binary integration tests for rakia,
    brit-verify, brit-build-ref, and 11 daily-driver brit subcommands
    (23 tests total in cli-journey)
  - cli-test-page crate: brit-test-page binary with --check/--update/
    --candidate modes, recursive --help discovery, coverage tracking,
    markdown formatter, similar-crate diff (11 self-tests)
  - tests/baseline.md: initial committed artifact, 31 covered subcommands
    across 4 binaries (34% combined; 100% on the 3 small binaries;
    daily-driver subset on brit)
  - Normalizer redacts ANSI/tempdir/timestamp/SHA + (this sprint)
    HH:MM:SS clock times, X.XXs durations, throughput rates
  - dump-to-staging helper added to utilities.sh for future shell-only
    test scenarios

Discoveries captured in sprint-result:
  - brit push not implemented in gitoxide upstream (gap notice in baseline)
  - brit commit is verify/sign/describe, not "make a commit"
  - brit branch and tag only have list subcommands
  - brit diff has its own subcommand tree (tree/file)
  - brit-verify uses hand-rolled arg parser, not clap

Sprint artifact: docs/superpowers/sprint-results/2026-04-19-brit-cli-test-page.md

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Latest upstream snapshot as of 2026-04-20. No push or commit-creation
changes relevant to our daily-driver gap (gitoxide's crate-status.md
confirms both are incomplete in the upstream library layer, not just
the CLI).

Pre-merge divergence:
  our main:      4094b73 (79 commits of brit-specific work)
  upstream/main: 7d50c30 (43 commits we don't have)
  merge-base:    26a5f65 (9 days ago)

# Conflicts:
#	Cargo.lock
#	Cargo.toml

…/main

Every 6 hours plus on-demand. Fast-forward only; a failed fast-forward
means gix-main has drifted and we want to know immediately rather than
paper over it with a merge commit.

gix-main is our pristine mirror of GitoxideLabs/gitoxide's main branch.
Feature branches for upstream PRs branch off gix-main, keeping the PR
diff clean of brit-specific commits.

Co-authored-by: Claude <claude@anthropic.com>

Upstream has 6000+ tags. A single collision with a protected tag name
(or a transient GitHub API hiccup partway through the push) would
otherwise fail the entire sync run, stopping gix-main freshness. Tags
are nice-to-have for our mirror, not load-bearing — gix-main's HEAD
pointing at upstream/main is what actually matters.

Log a warning if the tag push exits non-zero so we have a trail, but
don't fail the job.

Co-authored-by: Claude <claude@anthropic.com>

Tuned for brit's pure-Rust workspace — no holochain, no pnpm, no web
endpoints. Lower resource limits (6Gi mem / 2 CPU) suited to building
gitoxide + brit crates rather than the full elohim monorepo.

Adds a Che "Contribute" badge to the README pointing at
code.ethosengine.com so a devspace can be launched in one click.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Comment out setup-vscode-cli and setup-claude-mcp — these are the most
likely steps to fail on first start. Re-enable once the workspace is
known to come up cleanly.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

rust-analyzer indexing the gitoxide workspace alongside cargo, VS Code
server, and claude pushes past 6Gi and trips the OOM killer.

…iscipline

Two coordinated changes to raise Steward's value-per-invocation and lower
its flippancy risk:

Callee side (.claude/agents/gix-steward.md):
- Add CROSS-CUTTING-NOTE: line to PASS/REJECT/DESIGN-CHOICE/deferral
  templates. One sentence, cite file:line, "(none)" default. Not a
  smuggled DIRECTION-* verdict — pattern observation only, feeding the
  architect's moment GitoxideLabs#4 judgment.
- Add pre-flight cheap-reject inside moment #1 (completion gate): TODO
  markers, caller attestation, matrix-row = present, ledger current.
  Premature completion calls bounce without running clippy / feature
  matrix / parity.sh.
- Add "Cross-Cutting Observation Line" section spelling out the scope
  rules (observable only in already-gathered evidence, pattern not
  prescription, cite or skip, one sentence, empty is fine).
- Soften "No self-scheduled direction checks" to clarify that the
  CROSS-CUTTING-NOTE is not a back-door DIRECTION-ADJUST.

Caller side (etc/parity/prompt.md):
- Add "Pre-Steward self-check" attestation block to Completion section.
  Sonnet must truthfully sign 7 lines (flag count match, zero TODOs,
  parity.sh green, fmt/clippy clean, ledger current, matrix row staged,
  name 2-3 likely-reject rows) before invoking Steward for completion.
- Add "Steward invocation bar" per moment — explicit bars on what
  qualifies as a legitimate call, including moments GitoxideLabs#2/GitoxideLabs#3/GitoxideLabs#4.
- PASS flow now instructs the architect to read CROSS-CUTTING-NOTE and
  consider moment GitoxideLabs#4 before starting the next command.

Result: every Steward call does more cross-cutting work per invocation
(observation line) AND the invocation itself is harder for sonnet/haiku
to reach flippantly.